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(54) Scaleable and extensible system management architecture with dataless endpoints 

(57) A large distributed enterprise includes comput- 
ing resources that are organized into one or more.man- 
aged regions, each region being managed by a server 
machine servicing one or more gateway machines, with 
each gateway machine servicing a plurality of endpoint 
machines. A distributed system management frame- 
work is supported on the gateway machines and the one 
or more endpoint machines to carry out system man- 
agement tasks. To enhance scalability, the endpoint ma- 
chines support a low cost, low maintenance client com- 
ponent of. the system management framework, and a 
corresponding server component is supported on each 
of the gateway machines. On an as-needed basis, ap- 
propriate executable code and system management da- «> « 
ta is delivered from a gateway to one or more endpoint 
machines to facilitate execution o1 a system manage- 
ment task for the managed region. Typically, the system 
management data is not stored in the endpoint, and this 
"dataless" approach reduces the complexity and main- 
tenance costs associated with distributing the function- 
ality of the system management framework. The end- 
points are easily extensible to include new application 
functionality without requiring the overall framework to 
be rebuilt or reinstalled. 
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Description 

TECHNICAL FIELD 

The present invention is directed to managing a 
large distributed computer enterprise environment. 

BACKGROUND OF THE INVENTION 

Managing a computer network comprising thou- 
sands of nodes can produce serious difficulties for sys- 
tem administrators. Management tasks, such as distri- 
bution of system-wide changes, must be carried out 
quickly and in a dependable manner in order to reduce 
the probability of catastrophic failure. Distrbuted com- 
puting environments that are known in the art do not 
scale easily to large size. One of the root causes of this 
deficiency is that prior art management environments 
include high overhead applications that, typically, are 
run on all of the managed machines in the network. In 
such systems, even machines located at the bwest lev- 
el of management functionality (so>called "endpoints") 
often include a full suite of management routines and 
systems management data. Because the endpoint ma- 
chine has its own database, it has to be backed-up to 
accurately back up the overall environment. 

As the number of such machines gets large, the 
time to backup all the distributed databases becomes 
great and the backup storage requirements become un- 
manageable. When endpoint machines fail, or when us- 
ers accidentally remove files, It Is an enormous burden 
on system administrators to have to locate and restore 
the endpoint's database, especially if the missing data- 
base prevents the overall managed architecture from 
being able to distribute to the failed endpoint. Moreover, 
adding new application functionality to an endpoint ma- 
chine typically requires the overall management archi- 
tecture to be re-built, re-installed or at least, re-initlal- 
ized. This is a time-consuming, complex administrative 
task that severely limits the flexibility and increases the 
cost of system management. As a result of these prob- 
lems, it has not been possible to increase the size or 
"scalability" of such networks to a true "enterprise" level. 

The present invention addresses and solves these 
problems. 

BRIEF SUMMARY OF THE INVENTION 

It is a primary object of the invention to effectively 
manage computing resources in a large distributed en- 
terprise environment. 

it is another object of the invention to enable an en- 
terprise to place substantially all of its computing re- 
sources on a network that is managed in a reliable, cost- 
effective manner. 

It is still another object to reduce the complexity and 
cost of systems management in a large ent rprise en- 
vironmertt by supporting a low cost low maintenance 



managem nt framework on the vast majority of ma- 
chin s (e.g., the personal computers or PC/Es) in the 
enterprise. 

Yet another object is to enhance the scalability of a 
s large distributed computing network by distributing the 
functionality of a system management framework in ac- 
cordance with a "client-server" paradigm. 

A more specific object of the invention Is to imple- 
ment a low cost, low maintenance component of a sys- 
tem management framework at the endpoint machines 
that comprise the largest percentage of computing re- 
sources in the enterprise environment. 

It is another more particular object to support a min- 
imal set of applications on 'dataless* endpoint machines 
of a large, distributed environment to facilitate systems 
management. 

It is still another object of the invention to meet the 
needs of customers with very large and geographically- 
dispersed networks and, more particularly, to signifi- 
cantly expand the scalability parameters of traditional 
management tools and techniques. 

Yet another important object is to enable PC con- 
nectivity in a large centrally-managed network enter- 
prise. 

These and other objects are achieved in a targe dis- 
tributed enterprise that includes computing resources 
organized into one or more managed regions, each re- 
gion being managed by a server machine servicing one 
or more gateway machines, with each gateway machine 
servicing a plurality of endpoint machines. A system 
management framework is "distributed" on the gateway 
machines and the one or more endpoint machines to 
carry out system msmagement tasks. To enhance scale- 
ability, the endpoint machines support a low cost, low 
maintenance client component of the system manage- 
ment framework, and a corresponding server compo- 
nent is supported on each of the gateway machines. On 
an as-needed basis, system management data (and ex- 
ecutable code, if necessary) is delivei^ed from a gateway 
to one or more endpoint machines to facilitate execution 
of a system management task for the managed region. 
Typically, the system management data is not stored in 
the endpoint, and this "dataless" approach reduces the 
complexity and maintenance costs associated with dis- 
tributing the functionality of the system management 
framework. The endpoints are easily "extensible" to in- 
clude new application functionality without requiring the 
overall framework to be rebuilt or reinstalled. 

A preferred method of executing a system manage- 
ment task affecting the managed region begins by de- 
livering executable code and system management data 
required for the system management task from a gate- 
way machine to one or more endpoint machines serv- 
iced by the gateway. The executable is a shell script, a 
specializ d script, a compiled program or any other kind 
of valid ex cutable. When a system management task 
is created, the executable is stored on disk, and a ref- 
erence to the disk file is stored as an attribute in an ob- 
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ject database in the gateway machine. Upon r ceipt of 
the executable code and systenn management data 
from the gateway machine, the client component of the 
management framework (supported on the endpoint. 
machine) then carries out the management task. Pref- s 
erably. data is not cached on the endpoint. and the end- 
point returns to its nonmally. 'Idle' state after the task is 
completed. 

. An endpornt computer connectable into such an en- 
terprise thus includes a processor, an operating system. io 
a graphical user interface, and a client component of a 
system^rnanagement framework, the client component 
having an associated server component supported on 
a gateway machine that sen/ices that computer. The cli- 
ent component includes means responsive to receipt of is 
executables and system management data from the 
gateway machine to facilitate execution of a system^ 
management task into which the computer is connect- 
ed. Preferably, the system management framework Is 
object-oriented. 

The foregoing has outlined some of the more perti- 
nent objects of the present inventbn. These objects^ 
should be construed to be merely illustrative of some of 
the more prominent features and applications of the in- 
vention. M^ny other beneficial results can be attained 2S 
by applyingthe disclosed invention in a different manner 
or modifying the invention as will be described. Accord- 
ingly, other objects and a fuller understanding of the in- 
vention may be had by referring to the following Detailed 
Descriptfon of the preferred embodiment. 



FIGURE 6 illustrates the ORBmOA object-invoca- 
tion mechanism used by the present Invention; 
FIGURE 7 is a flowchart illustrating how a gateway 
machine invokes a method of an object running on 
an endpoint machine to facilitate a management 
task; 

FIGURE 8A is a flowchart illustrating how an end- 
point machine initiates a file pull system manage- 
ment operation; and 

FIGURE 8B is a flowchart illustrating how an end- 
point machine initiates an inventory system man- 
agement operation. 

DETAILED DESCRIPTION 



BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention and the advantages thereof, reference should 
be made to the following Detailed Description taken in 
connection with the accompanying drawings in whk:h:. 

FIGURE 1 illustrates a simplified diagram showing 
a large distributed computing enterprise environ- 
ment in which the present invention is implemented; 
FIGURE 2 is a bk)ck diagram of the system man- 
agement framework illustrating how the framework 
functionality is distributed across the gateway and 
Its endpoints within a managed region; 
FIGURE 2A is a block diagram of the elements that 
comprise the LCF client component of the system 
management framework; 

FIGURE 3 illustrates a smaller "workgroup" imple- 
mentation (e.g., a local area network) of the enter- 
prise in which the sen/er and gateway functions are 
supported on the same machine; 
FIGURE 4 shows a simplified representation of how 
a system administrator implements a system man- 
agement task; 

FIGURE 5 illustrates how management applica- 
tions are constructed in an object-oriented manner 
for use in the present invention; 



30 



35 



40 



46 



SO 



55 



Referring now to FIGURE 1. the invention is prefer- 
ably implemented in a large distributed computer envi- 
ronment 10 comprising up to thousands or even tens of 
thousands of 'nodes.' The nodes will typically be geo- 
graphically dispersed and the overall environment is 
"managed- in a distributed manner. Preferably, the man- 
aged environment (ME) is logically broken down into a 
senes of loosely-connected managed regions (MR) 12 
each with its own server 14 for managing local resourc^ 
es with the MR. Multiple sen/ers 14 coordinate activities 
across the enteirprise and permit remote site manage- 
ment and operation. Each sen/er 14 serves a number 
of gateway machines 16, each of which in turn support 
a plurality of endpoints 18. The sen/er 14 coordinates 
all activity within the MR using ateiminal node manager 

Referring nowto FIGURE 2, each gateway machine 
16 runs a sen/er component 22 of a system manage- 
ment framework. The sen/er component 22 is multi- 
threaded runtime process that comprises several com- 
ponents: an object request broker or "ORB" 21, an au- 
thorization sen/ice 23, object location sen/ice 25 and ba- 
sic object adaptor or "BOA' 27. Sen/er component 22 
also includes an object library 29. Preferably, the ORB 
21 runs continuously, separate from the operating sys- 
tem, and it communicates with both sen/er and client 
processes through separate stubs and skeletons via an 
interprocess communication (IPC) facility 19. In partic- 
ular, a secure remote procedure call (RFC) is used to 
invoke operations on remote objects. Gateway ma- 
chines 16 also Includes an operating system 15 and a 
threads mechanism 17. 

The system management framework includes a cli- 
ent component 24 supported on each of the endpoint 
machines 1 8. The client component 24 is a low cost, low 
maintenance application suite that is preferably 'data- 
less" In the sense that system management data is not 
cached or stored there in a persistent manner Imple- 
mentation of the management framework in this "client- 
s n/er- manner has significant advantages over the pri- 
or art, and it facilitates th connectivity of p rsonal corn- 
put rs into the managed environment. Using an object- 
onented approach, the system management framework 
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facilitates execution of system management tasks r - 
quired to manage the res urces In the MR. Such tasks 
are quite varied and include, without limitation, file and 
data distribution, network usage monitoring, user man- 
agement, printer or other resource configuration man- 
agement, and the like. System management tasks in- 
volve system management "data", which generally is 
the information collected or distributed as part of a par- 
ticular system management task. 

In the large enterprise such as illustrated in FIGURE 
1 . there is one sen/er per MR with some number of gate- 
ways. Fore wori^group-size installation (e.g., a local ar- 
ea networi< or "LAN") such as illustrated in FIGURE 3. 
a single sen/er-class machine may be used as the sen/- 
er and gateway, and the client machines would run the 
lost cost framework. References herein to a distinct 
sen/er and one or more gateway(s) should thus not be 
taken by way of limitation as these elements may be 
combined into a single platform. For intermediate size 
installations, the MR grows breadth-wise, with addition- 
al gateways then being used to balance the load of the 
enidpoints. 

The sender is the top-level authority over all gateway and 
endpoints. The sen/er maintains an endpoint list, which 
keeps track of every endpoint in a managed region. This 
list cbntkins all information necessary to uniquely iden- 
tify arid riianage endpoints including, without limitation, 
such information as name; location, and machine type. 
The sen/er also maintains the mapping between end- 
point and gateway, and this mapping is dynamic. Based 
on site-specific settings, it is possible to reassign end- 
points when gateways go down or to automatically add 
new endpoints as they appear on the network. 

As noted above, there are one or more gateways 
per managed region. A gateway is a full managed node 
that has been configured to operate as a gateway Ini- 
tially, a gateway "knows" nothing about endpoints. As 
endpoints login (discussed below), the gateway builds 
an endpoint list for its endpoints. The gatewa/s duties 
include: listening for endpoint login requests, listening 
for endpoint upcall requests, and (its main task) acting 
as a gateway for method invocations on endpoints. 

As also discussed above, the endpoint is a machine 
running the system management f ramewort^ client com- 
ponent, which is referred to herein as the low cost frame- 
work (LCF). The LCF has two main parts as illustrated 
in FIGURE 2A the Icf daemon 24a and an application 
runtime library 24b. The LCF daemon 24a is responsible 
for endpoint login and for spawning application endpoint 
executables. Once an executable is spawned, the LCF 
daemon 24a has no further interaction with it. Each ex- 
ecutable is linked with the application runtime library 
24b, which handles all further communication with the 



gat way. 

Preferably, the sender and each of the gateways Is 
a computer or 'machine.". For example, each computer 
may be a RISC System/6000 (a reduced instruction set 
or so-called RISC-based workstation) running the AIX 



(Advanced Interactive Executive) operating system, 
preferably Version 3.2.5 or greater. The AIX operating 
system is compatible at the application interface level 
with the UNIX operating system, version 5.2. 
5 The various models of the RISC-based computeirs 
are described in many publications of the IBM Corpora- 
tion, for example. RISC Svstem /fiQOQ. 7073 and 7016 
POVtfERstation and POWERsen/er Hardware Technical 
Reference, Order No. SA23-2644-00. The AIX operat- 
10 ing system is described in AIX Opera ting System Tech- 
nical Reference, published by IBM Corporation. First 
Edition (November, 1 985), and other publications. A de- 
tailed description of the design of the UNIX operating 
system is found in a book by Maurice^J. Bach, Design 
IS of the Unix QperatinQ Svstem. published by Prentice- 
Hall (1986). Suitable alternative machines include: 4n 
IBM-<^patible PC 486 or higher running Novell Unix- 
Ware 2.0, an AT&T 3000 series running AT&TUNIX 
SVR4 MP-RAS Release 2.02 or greater. Data General 
20 AViiON series mnning DGAiX version 5.4R3.00 or 
greater, an HP9000/700 and 800 series mnning HPAJX 
9.00 through HP/UX 9.05. Motorola 88K series running 
SVR4 version R40V4.2. a Sun SPARC series running 
Solaris 2.3 or 2.4, or a Sun SPARC series mnning Su- 
25 nOS 4:1 .2 or 4.1 .3. Of course. 6ther maichihes and/or 
operating systems rriay be used as well for the gateway 
and sender machines. 

Each endpoint is also a computer: In one preferred 
embodlmerit of the invention, most of the endpoints are 
30 personal computers (e.g., desktop machines or lap- 
tops). In this architecture, the endpoints need not be 
high powered or complex machines or workstations. 
One or more of the endpoints may be a notebook com- 
puter, e.g.. the IBM ThinkPads machine, or some other 
35 Intel x86 or Pentium«-based computer running Win- 
dows 3.1 or greater operating system. IBM« or IBM- 
compatible machines running under the OS/2" operat- 
ing system may also be implemented as the endpoints. 
For more information on the OS/2 operating system, the 
40 reader is directed to OS/2 2.0 Te chnical Library. Pro- 
gramming Guide Volumes 1-3 Version 2.00. Order Nos. 
10G6261, 10G6495and 10G6494. 

noted above, the sen/er-class framework run- 
ning on each gateway machine is multi-threaded and is 
45 capable of maintaining hundreds of simultaneous net- 
work connections to remote machines. A thread of ex- 
ecution may be a separate process (in the UNIX para- 
digm) or a separate thread in a single process (in the 
POSIX pthreads paradigm). POSIX is a series of stand- 
so ards for applications and user interfaces to open sys- 
tems, issued by the Institute of Electrical and Electronics 
Engineers Inc. (IEEE). The IEEE POSIX.lc is the 
emerging standard for user level multi -threaded pro- 
gramming and is implemented in the served component 
ss of th systems management framework. All objects in 
this framework xhibit "state." This state may be com- 
pletely persistent, in which case it is represented by at- 
tributes in the object database associated with a gate- 
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way machine, or the state may be non-persistent. An 
example of the latter might be the current list of ma- 
chines that are down.: 

In the preferred embodiment, the LCF is the small- 
est amount of code that can still do useful endpoint work, s 
Generally, this means that the LCF code has the follow- 
ing characteristics: single4hreaded.. limited cascade^ 
and upcall capability, no persistent attributes and only a . 
small setvOf CORBA runtime. Machines that see littles^^ 
management activity in a typical day are those for which ■ io 
the LCFJs particularly advantageous. Machines that 
need tO'.service a large volume of requests preferablyr 
run the server component of the system management- 
framework. . 

The LCF is always ready to do management tasks, is 
but consumes few resources because it is normally In 
an idle state. Preferably, each endpoint is "dataless" in^ 
the sense that system management data is not stored* . 
therein before or after a particular system management 
task is implementedpr carried out. Therefore, unlike the^ 20 
prior art, there is no need to perform system backup or 
other conventional rnaintenance on the : endpoint (at^ 
least with respect to the system management frame- 
work). Maintenance on the sen/er and gateway ma- 
chines suffices.vSimllarly, new application functionality 2S 
may be added tO: the Icf without rebuilding, reinstalling 
or re-initializing^the client component into the system; 
managenient framework. 

Since endpoints are dataless and readily extensir 
ble, the architecture is easily scaleable as illustrated in 30 
FIGURE 1. The client component of the system man- 
agement framework is inexpensive and requires little or 
no maintenance since much of the system management 
framework is off-loaded to the gateway machines that 
run the multi-threaded, server component. This archi- 3S 
lecture advantageously enables a rational partitioning 
of the enterprise. with 10*s of servers^ 100's of gateway - 
machines, and lOOO'sof endpoints. Each server typical- 
ly serves up to 200 gateways, each of whrch services 
lOOO's of endpoints. At the framework level, all opera- 4o 
tions to or from an endpoint pass through a gateway ma- 
chine. In many operations, the gateway is transparent; 
it receives a request, detemnines the targets, resends 
the requests, waits for results, then retums results back 
to the caller Each gateway handles multiple simultane- 4S 
ous requests, and there may be any number of gate- 
ways in an enterprise, with the exact number depending 
on many factors including the available resources and 
the number of endpoints that need to be serviced. 

Thus, according to the present invention, one or so 
more of the endpoints 18 are "dataless." Except for the 
LCF executable itself, preferably there is no database 
or other state that must be kept on the endpoint. When- 
ever executable code and/or system management data 
are needed for a particular system management task, ss 
such code and/or data are delivered from a particular 
gateway machine to the affected endpoints machines 
automatically. Typically, the executable code and/or da- 



ta will remain valid for the particular task invocation; 
while the executable code rnay be cached, usually Ihe 
system management data will not be. If the executable 
code is cached, preferably the syst m management 
framework may be configured to automatically resend 
such code without operator interventksn if the cache is 
lost or periodically flushed. 

An endpoint is added to the enterprise by first cop- 
ying the LCF daemon 24a to the endpoint's disk. This 
may be done automatically through network login 
scripts, manually by inserting a diskette, or by preload-* 
Ing the boot disk at the time of purchase or license. The* 
first time the LCF daemon is installed, and on each sub- 
sequent boot, the LCF daennon attempts to login to its 
gateway If the gateway is not known or if the gateway; 
does not respond, the daemon issues a broadcast^ re-^ 
questing a gateway. For completely new endpoints the 
broadcast is ultimately forwarded to the server. If a gate- 
way hears a broadcast or a loghi request from an end- 
point it recognizes, the gateway services the request it- 
self. 

When the server receives an endpoint* s gateway re- 
quest broadcast, the server consults its endpoint list to 
see which gateway the endpoint belongs to. For new 
endpoints, or when migrating between gateways, the 
server uses a site specific policy to choose the correct 
gateway (e.g., by subnet). The gateway is inforimed of 
its new endpoint, the gateway informs the endpoint, and 
the login completes. 

An endpoint preferably communicates only with Its 
gateway. Requiring all endpoint communication to pass 
through a single gateway greatly simplifies connectivity 
issues. After a successful login, both endpoint and gate- 
way know a working address by which to address one 
another If a DHCP address lease expires, or anything 
changes in the network topology, then the next endpoint 
login will establish the new endpoint to gateway ad- 
dresses. 

There is no absolute maximum number of endpoints 
that can be supported by a single gateway The design 
strategy is that the gateway is always in control of its 
own workload. The endpoints are not allowed to send 
data unless granted permission. When an endpoint has 
results to return, or if it wishes to make an upcall, it sends 
a very small message requesting service. The (gateway 
queues the request and services the queue as time al- 
lows. When an endpoint has large results, it must break 
the results into chunks and may only send a chunk when 
instructed to do so. This strategy makes it possible for 
a single gateway to support thousands of endpoints. al- 
beit somwhat slowly. If a better quality of service is de- 
sired, it is simply a matter of adding more gateways. 

Endpoint methods are normal CORBA methods (as 
discussed below) link d with IDL compiler generated 
code and the endpoint application runtime library 24b. 
This results in a native executable designed to be 
spawned by the LCF daemon 24a. Any number of meth- 
ods may be implemented In a single xecutable. 
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Preferably, an endpoint Is installed without any 
methods. Method executables ar downloaded from the 
gateway as required. When the LCF daemon receives 
a method invocation request, it checks the local disk 
cache. If there is a cache miss, or a version mismatch, 
then a new executable is downloaded. In this way, an 
endpoint can start with nothing and then build a working 
set of methods lor fast execution. 

Before illustrating how the framework is used, the 
following background is provided. FIGURE 4 first illus- 
trates how a systems management task is implemented. 
Each authorized administrator 30 has access to a desk- 
top computer 32 containing one or more icons repre- 
senting system resources. As administrators interact 
with dialog screens and menus available from these 
icons, they are able to change system configurations 
and manage new resources in the distributed environ- 
ment, all in a known manner. In particular, when admin- 
istrator 30 interacte with the: desktop, so-called 'call- 
backs" (i.e. software that responds to the user's actions) 
are invoked from the user interface on undertying ob- 
jects representing some system resource or compo- 
nent These callbacks are translated into a series of 
method invocattons that actually perform the work and 
return results or status to the administrator. In particular, 
and with reference to the process flow diagram of FIG- 
URE 4, the information flow begins when the adminis- 
trator 30 selects an icon or interacts with a dialog. The 
information is then sent to the desktop (which may be 
connected to a sender or a gateway) at step 34. at which 
time the appropriate application callback method is in- 
voked at step 36. The callback method then invokes 
core applicatton methods at step 38. which communi- 
cate with the application obiect(s) to perform some sys- 
tem management operation, as illustrated at step 39. 
Any retum information or state is passed back at steps 
40 and 41 . If an update to the user interface is required, 
the desktop 32 interprets the output and updates the di- 
alogs on the administrator/Es desktop at step 42. 

Preferably, the framework includes a task library 
that enables administrators to create "shell" scripts that 
can run an any managed node of the enterprise envi- 
ronment. A shell script integrated with a managed node 
is called a task.' When administrators want to create a 
task, they provide a machine and a path to an executa- 
ble file. The executable can be a shell script, a special- 
ized script, a compiled program or any other kind of valid 
executable. When a task is created, the executable is 
stored as an attribute in an object database associated 
with a gateway machine. When the task is needed, the 
executable file is retrieved from the attribute and is pro- 
vided to one or more managed nodes. After a task is 
created, it is added to the task library and displayed as 
an icon. 

FIGURE 5 illustrates how systems management 
applications ar constructed from a set of standard ob- 
ject types that together constitute a general applications 
architecture for the fram work. These standard object 



types are closely interrelated and are used to build ob- 
jects for system management applications. The objects 
provided by a management application can be divided 
into one or more object types 44 that are managed by 
s one or more instance manag rs 46. An object typ is a 
set of objects that share a common interface. Each ob- 
ject of the same type is called an instance of the type. 
Within the systems management framework, object 
types are associated with a particular instance manager. 
10 The instance rhanagers are registered and stored in a 
library 48. which provides a central repository for system 
administratran object infomnation within a manaiged re- 
gion- 

As referenced above, the systems management 
15 provides an implementation of a CORBA 1 . 1 Object Re- 
quest Broker (ORB), bask: object adaptor (BOA), and 
related object sendees. CORBAI.I is a specification for 
an object-oriented distributed computer systems man- 
agement architecture provided by The Object Manage- 
20 ment Group (OMG). a non-profit association of more 
than 300 companies. CORBA describes the use of the 
Object Request Broker (ORB) and bask: object adaptor 
(BOA) that provide a mechanisnrt for object invocation 
and return of results. The specification defines interfac- 
es es to a set of low-level object sen/ices and enables such 
- sen/icestobe lntegratedinmany different language arid 
systems using object encapsulation, sen/ice requestor/ 
provider isolation, and interface and implementation 
separation. 

30 In a CORBA 1 .1 implementation as seen in FIGURE 
6, there are three primary components: a client, an ob- 
ject implementation, and the ORB/BOA. The client 50 is 
the requestor of a sen^ice that is providisd by an object 
implementation 52. The ORB 21 delivers the request 
3S from the client 50 to the object implementation 52 
through the BOA 27. The object implementation 52 then 
performs the requested sen/ice, and any returri data is 
delivered back to the client. The client and object imple- 
mentation are isolated from each other, and neither has 
40 any knowledge of the other except through their ORB/ 
BOA interfaces. Client requests are independent of the 
object implementation location and the programming 
language in which they are implemented. 

The ORB delivers the request to the BO/V, which 
45 activates the process under which the object implemen- 
tation (e.g.. a sender) runs. The BOA then invokes the 
method associated with the request by way of a sen/er 
skeleton 61. When the method is finished, the BOA 
manages the termination of the method and coordinates 
so the return of any results to the client. Altematively. if a 
request is unknown until runtime, a Dynamic Invocation 
Interface (DM) 55 is used to build a request used in place 
of a client stub 63 linked at compile time. 

With the above background, several examples ot 
55 how system management tasks are carried out using 
the client-server framework are now described. The fol- 
lowing discussion is mer ly exemplary, as the natur 
and type of systems management tasks that can be car- 
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ried out by the framework is unconstrained. As noted 
above, the system management framework Includes the 
sen/er component supported on the gateway machines 
of the managed region, and the associated client com- 
ponent is supported on the endpolnts serviced by th s 
gateway(s). To provide transparent functionality, every, 
method tobe run on an endpoint is preferably configured' 
on the gateway. All endpoint object references (Objrefs) 
that other rnethods use to invoke operations on an end- 
point are Objrefs and each endpoint is assigned to a io 
unque object dispatchernumber (odnum). The gateway 
machine tlien uses true object references to 'point' to 
the actualNendpoint(s). 

The routine illustrated in FIGURE 7 occurs when 
one method invokes a method of an object on an end- 
point. At step 70, the sender 1 4 resolves the Objref/imeth- 
od to a specific method daemon on a gateway. At step 
72, the gateway Is started (if it is not already running) 
and passed a method activation record or so-called 
MAR block. The MAR block contains all information nec- 20 
essary to invoke a method Jncluding the target Objref, 
the target method, 'marshalled' input arguments and 
other fields from the server's method store. As noted 
above vyith respect to FIGURE 6, when a request to run 
an operation on some object is made, a client stub ini- 2S 
tiates the request, collects the data associated with the 
request, and converts It from its current format to a com- 
mon format. This process is known as 'data marshal- 
ling' and is performed in accordance with the ASN.1 
Standard. Up to this point, there Is no difference as far 30 
as the application is concemed between this method in- 
vocation and any other method invocation. At step 74, 
the gateway looks at the Objref to determine the target 
endpoint. A connection to the endpoint is then opened 
at step 76. 35 

The method continues at step 78 and queries 
whether the endpoint has a copy of the executable for 
the method. If not, the routine continues at step 80 to 
retrieve the appropriate executable from the object da- 
tabase (based on the endpoint's machine type), and the 
executable is then sent to the endpoint. At step 82. or if 
the endpoint already had the necessary executable, the 
gateway sends the still-marshalled input arguments to 
the endpoint. At step 84, the gateway enters into a watt 
state, waiting for the marshalled output arguments to be 4S 
returned. When this occurs, the routine continues at 
step 86 and closes the connection to the endpoint. The 
output arguments are then sent back to the server at 
step 88 and th e routine terminates as though the method 
had executed locally. so 

Endpoint-lnltiated operations can now be de- 
scribed In these types of operations, the endpoint first 
attempts to establish a connection back to its gateway 
Preferably, this is done in the same way that the end- 
point client attempts to Identify itself upon boot. It first SS 
tries its last known gateway host; if it gets no response, 
the endpoint then contacts the server's TN Manager rou- 
tine Ither directly or. if that fails, via a BOOTP broad- 



cast. Once connected, the s rver component of the 
gateway is Invoked and the endpoint passes a descrip- 
tor telling the gateway which endpoint has connected. 

Upcalls are method requests originating at the end- 
point. The Tivoli Courier"** pull interface is an example 
of a program making upcalls. Not ail applications wilt 
need upcalls. An endpoint makes an upcall by calling; 
an IDL compiler generated stub. Unlike a normal meth-f 
od invocation, an upcall always invokes a special upcall/ 
method on the gateway. An applcatlon that supports up- 
calls must provide both the endpoint code and the spe- 
cial upcall method. The endpoint upcall facility is not a 
general purpose method invocation interface. This de- 
sign maintains scalability by handling upcalls at the local 
gateway without management server intervention. 

An illustrated Tile pull' operation is shown in FIG- 
URE 8A. In this operation, the endpoint-resident code 
(i.e. the client component) initiates a file request, and 
the gateway-resident code (i.e. the server component) 
handles the request. The routine begins at step 96;. with 
the user on the endpoint invoking a local program that 
is part of the client component of a file distribution ap- 
plicaton. This step invokes a method asking for a list of 
all available filepacks. A 'filepack" is a collection of files 
being distributed in accordance with a system manage- 
ment task. At step 98. the gateway receives the request, 
invokes the server component of the file distribution ap- 
plication, passing it the descriptor kientifying the end- 
point. The software distributbn program, running as a 
method on the gateway, issues a name service lookup 
at step 100, filters out filepacks that the endpoint is al- 
lowed to receive at step 102, and then returns the list to 
the endpoint at step 104. Depending on the actions of 
the user, the endpoint may then invoke another method 
asking for a specific filepack. 

FIGURE 8B illustrates an inventory reporting sys- 
tem management task. In this example, assume that an 
inventory application is designed to collect Inventory in- 
formation (e.g., the hardware and software configura- 
tion details) from a machine whenever the machine is 
rebooted. It is also assumed that an initialization method 
has been run on each endpoint to edit the appropriate 
boot-time script to run the.inventory report program on 
boot. The routine starts upon the next boot. In particular, 
at step 106, the program runs the local inventory report 
to produce a data file of inventory results. At step 108, 
the endpoint connects to the gateway in the manner pre- 
viously described. The endpoint then invokes an 'inven- 
tory report" method at step 110 and, at step 112, sends 
the results to the gateway. At step 114, the server com- 
ponent of the inventory report method is invoked and 
passed a descriptor identifying the endpoint. The inven- 
tory results are read by the gateway at step 116 and, at 
step 118, forwarded to a central inventory database ob- 
ject. 

The LCF is designed with efficient distributions op- 
erations in mind. Each gateway is also a repeater for 
each of the gateway's endpolnts. This r lationship is im- 
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plicit so it does not need to be set in the repeater con- 
figuration. Distributions fan out from the gateway to the 
endpolnts without further server support. Eliminating the 
server as a bottleneck makes distributions very scalea- 
ble.. 

As can be seen, the endpoint remains essentially 
dataless except as needed to carry out the particular 
system management task. This operation Is facilitated 
by distributing the system management framework 
across client components, supported on the ehdpoints, 
and server components, supported- on the gateways 
that sen^ice.the endpoints. 

As noted above, the LCF is extensible and thus new 
application functionality is easily added to the system 
management framework without having to rebuild or re- 
install the client component at the endpoint. The specif- 
ics on how the LCF is installed and activated vary from 
OS type: to OS type. On some operating systems there 
is a background task (e.g., inted on:Unix) that listens for 
incoming network connections. On other operating sys- 
tems, the Icf Itself is configured as a background task 
that Is dormant until a networic request activates it. In all 
cases, a persistent network listener of the Icf is relatively 
small. The network listener will fork/spawn/invokeahe 
= larger application component (as, the case may be) in 
response to a request from the client. 

According to the invention, the; code running on 
each' endpoint is a small subset of a object-oriented 
CORBA runtime. This subset has sufficient functionality 
to implement methods such as the filepack distribution 
methods and CCMS profile endpoint methods (dataless 
. model). ;The basic components are ADR encoding rou- 
tines for argument marshaling, standalone IPC library, 
bdt (block data transfer) and lorn, message catalogs for 
118N, memory management and exception handling. 

One of the preferred implementations of the client 
component of the system management framework is as 
a set of instructions in a code module resident in the 
random access memory of the endpoint. Until required 
by the computer, the set of instructions may be stored 
in another computer memory, for example, in a hard disk 
drive, or in a removable memory such as an optical disk 
(for eventual use in a CD ROf^) or floppy disk (for even- 
tual use in a floppy disk drive), or even downloaded via 
the Internet. In addition, although the various methods 
described are conveniently implemented in a general 
purpose computer selectively activated or reconfigured 
by software, one of ordinary skill in the art would also 
recognize that such methods may be carried out in hard- 
ware, in firmware, or in more specialized apparatus con- 
structed to perform the required method steps. 

Further, although the invention has been described 
in terms of a preferred embodiment in a specific network 
environment, those skilled in the art will recognize that 
the inv ntion can be practiced, with modification, in oth- 
er and differ nt network architectures with the spirit and 
scope of the appended claims. The present invention, 
however, is not to be construed as limited to the partic- 



ular managed architectur illustrated and thus in a more 
general sense the inventive us of a client-serv r man- 
aged framework should be broadly construed to be use- 
ful in any distributed networic configuration. 

5 - . 

Claims 

1. A method of managing computing resources in a 
10 large distributed enterprise, • comprising the steps 

ot 

organizing the computing resources into one or 
more managed regions, each regk>n being 
IS managed by a server machine servteing one or 

more gateway machines, each gateway ma- 
. chine servicing , a plurality of endpoint ma- 
. chines; and 

20 _ :; delivering, on an as-needed basis, executable 
code and system management data from a 
gateway to one or more endpoint machines 
seo^iced by the gateway to facilitate execution 
of at least one system management task aff ect- 

25 ingthemanaged region in the one or riioreend- 

poffit machines. 

2. The method as described in Claim 1 wherein data 
is used by the one or more endpoint machines to 

30 . facilitate execution of the system management task 
. and is not stored for subsequent use.f 

3. The method as described in Claim 1 further includ- 
ing the step of caching the executable code for sub- 

35 sequent use. 

4. The method as described m Claim 1 further includ- 
ing the step of maintaining the computing resources 
by backing up system management data only from 

40 the sender and the one or more gateway machines. 

5. The method as described in Claim 1 wherein at 
. least some of the endpoint machines are personal 
computers. 

45 

6. The method as described in Claim 1 wherein each 
ot the endpoint machines runs a client component 
of a system management framework and wherein 
the gateway machine that services the endpoint 

50 machines runs a server component of the system 
management framework. 

7. The method as described in Claim 6 wherein the 
client component of the system management 

55 framework has an operating state that is normally 

idle. 

8. The method as described in Claim 6 wher in the 
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server component of the system management gateway machine and for spawning an executable 

framework executes in a multi-threaded fashion. downloaded from the gateway machin . 



9. In a large distributed enterprls wherein computing 
resources are organized into one or more managed s 
regions, each region being managed by a server 
machine sen/Icing one or more gateway machines, 
each gateway machine servicing a plurality of end- 
point machines, a method of executing a system 
management task affecting a managed region, io 
comprising the steps of : 

delivering executable code and system man- 
agement data required for the system manage- 
ment task from a gateway machine to one or 
more endpoint machines serviced by the gate- 
way; and 

using a distributed system management frame- 
work supported on the gateway machine and 20 
the one or more endpoint machines to carry out 
the system management task using the execut- 
able code and system management data. 

10. In the enterprise as described In Claim 9 wherein 2S 
the distributed system management framework in- 
cludes a client component supported on each of the 
one or more endpoint machines and a server com- 
pprient supported on the gateway machine that 
services the one or more endpoint machines. 30 



1 1 . A computer connectable into a large distributed en- 
terprise having a server machine servicing a set of 
gateway machines, each of which services a set of 
endpoint machines, comprising: 3S 

a processor; 

an operating system; and 

40 

a client component of a system management 
framework, the client component having an as- 
sociated server component supported on a 
gateway machine; wherein the client compo- 
nent of the system management framework in- 4S 
eludes means responsive to receipt of execut- 
ables and system management data from the 
gateway machine to facilitate execution of a 
system management task affecting the man- 
aged region into which the computer is con- so 
nected. 



12. The computer as described in Claim 11 wherein the 
means includes a daemon and an application runt- 
ime library, ss 

13. The computer as d scribed in Claim 12 wherein the 
LCF daemon is responsibi for endpoint login to a 
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